Security for prose group communication

ABSTRACT

A method of performing authentication and authorization in Proximity based Service (ProSe) communication by a requesting device ( 31 ) which sends a request of a communication and a receiving device ( 32 ) which receives the request from the requesting device ( 31 ) and ( 32 ), the method including deriving session keys Kpc and Kpi from an unique key Kp at the requesting and receiving devices ( 31 ) and ( 32 ), using the session keys Kpc and Kpi for ProSe communication setup and direct communication between the requesting and receiving devices ( 31 ) and ( 32 ), starting the direct communication with the requesting and receiving devices ( 31 ) and ( 32 ). The key Kpc is confidentiality key and the key Kpi is integrity protection key.

TECHNICAL FIELD

This invention is related to a secure system and a method of performingauthentication and authorization, more specifically, to a method ofperforming the authentication and the authorization in Proximity basedService (ProSe) communication.

BACKGROUND ART

3GPP (3rd Generation Partnership Project) has started to study Proximitybased Services (ProSe) for both commercial and public safety uses. 3GPPSA1 (Services Working Group) has initiated some security requirementsfor secure communication, UE (User Equipment) identity, and privacyprotection.

ProSe represents a recent and enormous socio-technological trend. Theprinciple of these applications is to discover instances of theapplications running in devices that are within proximity of each other,and ultimately to also exchange application-related data. In parallel tothis, there is interest in proximity-based discovery and communicationsin the public safety community.

ProSe communication can provide services to the UEs in proximity via aneNB (Evolved Node B) or without the eNB. The SA1 requires that the ProSeservice be provided to UEs with or without network coverage. The UEs candiscover other nearby UEs or be discovered by other UEs, and they cancommunicate with each other. Some use cases can be found in NPL 1.

CITATION LIST Non Patent Literature

NPL 1: 3GPP TR 22.803 Feasibility study for Proximity Services (ProSe),(Release 12)

SUMMARY OF INVENTION Technical Problem

However, despite the security issues involving authentication andauthorization for direct communication as well as privacy issues, 3GPPSA3 offers no security solution.

Solution to Problem

The present invention has been made to present an overall securitysolution for the above-mentioned security issues.

[0008] In one embodiment, there is provided a method of performingauthentication and authorization in Proximity based Service (ProSe)communication by a requesting device which sends a request of acommunication and a receiving device which receives the request from therequesting device, the method including deriving session keys Kpc andKpi from an unique key Kp at the requesting and receiving devices, usingthe session keys Kpc and Kpi for ProSe communication setup and directcommunication between the requesting and receiving devices, starting thedirect communication with the requesting and receiving devices. The keyKpc is confidentiality key and the key Kpi is integrity protection key.

In another embodiment, there is provided a secure system including aplurality of User Equipments (UEs), and a Proximity based Service(ProSe) server, including a requesting device which sends a request of acommunication, and a receiving device which receives the request fromthe requesting device. The requesting and receiving devices derivesession keys Kpc and Kpi from an unique key Kp. The requesting andreceiving devices use the session keys Kpc and Kpi for ProSecommunication setup and direct communication between the requesting andreceiving devices. The requesting and receiving devices start the directcommunication with the requesting and receiving devices. The key Kpc isconfidentiality key and the key Kpi is integrity protection key.

Advantageous Effects of Invention

A secure system and a method of making a secure communication canpresent an overall security solution for security issues.

BRIEF DESCRIPTION OF DRAWINGS

The above and other objects, advantages and features of the presentinvention will be more apparent from the following description ofcertain preferred embodiments taken in conjunction with the accompanyingdrawings, in which:

FIG. 1A is a schematic view showing the ProSe Communication scenario inNPL 1;

FIG. 1B is a schematic view showing the ProSe Communication scenario inNPL 1;

FIG. 2 is a schematic view showing an example of the systems whichprovide a method of making a secure communication according to anexemplary embodiment of the present invention;

FIG. 3 is a schematic view showing a secure system of an exemplaryembodiment of the present invention;

FIG. 4 is a sequence diagram explaining a method of making a securecommunication of an exemplary embodiment of the invention;

FIG. 5A is a schematic view showing a One-to-one session;

FIG. 5B is a schematic view showing a One-to-many session; and

FIG. 5C is a schematic view showing a Many-to-many session.

FIG. 6 is a sequence diagram showing One-to-one communication of anexemplary embodiment of the present invention;

FIG. 7 is a sequence diagram showing the option 1 of One-to-manycommunication of an exemplary embodiment of the present invention;

FIG. 8 is a sequence diagram showing the option 2 of One-to-manycommunication of an exemplary embodiment of the present invention; and

FIG. 9 is a sequence diagram showing Many-to-many communication of anexemplary embodiment of the present invention.

DESCRIPTION OF EMBODIMENTS

For purposes of the description hereinafter, the terms “upper”, “lower”,“right”, “left”, “vertical”, “horizontal”, “top”, “bottom”, “lateral”,“longitudinal”, and derivatives thereof shall relate to the invention asit is oriented in the drawing figures. However, it is to be understoodthat the invention may assume alternative variations and step sequences,except where expressly specified to the contrary. It is also to beunderstood that the specific devices and processes illustrated in theattached drawings, and described in the following specification, aresimply exemplary embodiments of the invention. Hence, specificdimensions and other physical characteristics related to exemplaryembodiments disclosed herein are not to be considered as limiting.

In the exemplary embodiments, though the security solutions with a focuson specifically direct communication, discovery, and communication willbe explained, the solutions can be applied to other communications aswell.

Firstly, definitions given in 3GPP TR 21.905: “Vocabulary for 3GPPSpecifications” will be explained.

ProSe Direct Communication:

A communication between two or more UEs in proximity that areProSe-enabled, by means of user plane transmission using E-UTRAtechnology via a path not traversing any network node.

[0016]

ProSe-Enabled UE:

A UE that supports ProSe requirements and associated procedures. Unlessexplicitly stated otherwise, a Prose-enabled UE refers both to anon-public safety UE and a public safety UE.

ProSe-Enabled Public Safety UE:

A ProSe-enabled UE that also supports ProSe procedures and capabilitiesspecific to Public Safety.

ProSe-Enabled Non-Public Safety UE:

A UE that supports ProSe procedures but not capabilities specific topublic safety.

ProSe Direct Discovery:

A procedure employed by a ProSe-enabled UE to discover otherProSe-enabled UEs in its vicinity by using only the capabilities of thetwo UEs with rel.12 E-UTRA technology.

EPC-Level ProSe Discovery:

A process by which the EPC determines the proximity of two ProSe-enabledUEs and informs them of their proximity.

FIGS. 1A and 1B are schematic views showing the ProSe Communicationscenarios in NPL 1. When a UE 11 and a UE 12 which are involved in theProSe Communication are served by the same eNB 19 and network coverageis available, a system 100 a can decide to perform ProSe Communicationusing control information exchanged between the UEs 11, 12, eNB 19 andan EPC (Evolved Packet Core) 14 (e.g., session management,authorization, security) as shown by the solid arrows in FIG. 1A. Forcharging, modifications should be minimized with respect to the existingarchitecture. The UEs 11 and 12 can in addition exchange controlsignaling via the ProSe Communication path as shown by the dashed arrowin FIG. 1A.

When the UEs 11 and 12 involved in the ProSe Communication are served bydifferent eNBs 19, 20 and network coverage is available, a system 100 bcan decide to perform ProSe Communication using control informationexchanged between the UEs 11, 12, eNB 19 and the EPC 14 (e.g., sessionmanagement, authorization, security) as shown by the solid arrows inFIG. 1B. In this configuration, the eNBs 11 and 12 may coordinate witheach other through the EPC 14 or communicate directly for radio resourcemanagement as shown by the dashed arrow between the eNBs 11 and 12 inFIG. 1B. For charging, signaling modifications should be minimized withrespect to the existing architecture. The UEs 11 and 12 can in additionexchange control signaling via the ProSe Communication path as shown bythe dashed arrow between the UE 11 and the UE 12 in FIG. 1B.

If network coverage is available for a subset of the UEs, one or morePublic Safety UEs may relay the radio resource management controlinformation for other UEs that do not have network coverage.

If network coverage is not available, the control path can existdirectly between Public Safety UEs. In this configuration, the PublicSafety UEs can rely on pre-configured radio resources to establish andmaintain the ProSe Communication. Alternatively, a Public Safety RadioResource Management Function, which can reside in a Public Safety UE,can manage the allocation of radio resources for Public Safety ProSeCommunication.

FIG. 2 is a schematic view showing an example of the systems whichprovide a method of making a secure communication according to anexemplary embodiment of the present invention. As shown in FIG. 2, asystem 10 includes the UE 11, the UE 12, an E-UTERN 13, the EPC 14, aProSe Function 15, a ProSe APP Server 16, a ProSe APP 17, and a ProSeAPP 18.

The UE 11 and the UE 12 can communicate through a PC5, the UE 11 and theE-UTERN 13 communicate through LTE-Uu1, and the UE 12 can communicatewith the E-UTERN 13 and the ProSe Function 15 through LTE-Uu2 and a PC3,respectively. The EPC 14 and the ProSe Function 15 can communicatethrough a PC4, the ProSe APP server 16 can communicate with the EPC 14and the ProSe APP 18 through a SG1 and a PC1, respectively, and theProSe Function 15 can communicate by itself through a PC6.

As described above, existing keys can be used when using aninfrastructure, i.e., via eNodeB. However, a new solution is needed fordevice-to-device direct discovery and communication; for example, a keycan be sent from the network to communicating parties, a key can becreated between communicating parties, or a similar algorithm fornegotiation can be used directly or via the network. Further, a newsolution is also needed for the security over the unlicensed spectrum.

Two different modes for ProSe Direct Communication one-to-one aresupported:

Network independent direct communication: This mode of operation forProSe Direct Communication does not require any network assistance toauthorize the connection and communication is performed by using onlyfunctionality and information local to the UE. This mode is applicableonly to pre-authorized ProSe-enabled Public Safety UEs, regardless ofwhether the UEs are served by E-UTRAN or not.

Network authorized direct communication: This mode of operation forProSe Direct Communication always requires network assistance and mayalso be applicable when only one UE is “served by E-UTRAN” for Publicsafety UEs. For non-Public Safety UEs both UEs must be “served byE-UTRAN”.

PC1:

It is the reference point between the ProSe application 18 in the UE 12and in the ProSe App Server 16. It is used to define application levelrequirements.

PC2:

It is the reference point between the ProSe App Server 16 and the ProSeFunction 15. It is used to define the interaction between the ProSe AppServer 16 and ProSe functionality provided by the 3GPP EPS via the ProSeFunction 15. One example of use of it may be for application dataupdates for a ProSe database in the ProSe Function 15. Another exampleof use of it may be data for use by the ProSe App Server 16 ininterworking between 3GPP functionality and application data, e.g. nametranslation.

PC3:

It is the reference point between the UE 12 and the ProSe Function 15.It is used to define the interaction between the UE 12 and the ProSeFunction 15. An example of use of it is for configuration for ProSediscovery and communication.

PC4:

It is the reference point between the EPC 14 and the ProSe Function 15.It is used to define the interaction between the EPC 14 and the ProSeFunction 15. Possible use cases of it may be when setting up aone-to-one communication path between UEs or when validating ProSeservices (authorization) for session management or mobility managementin real time.

PCS:

It is the reference point between the UE 11 to the UE 12 used forcontrol and user plane for discovery and communication, for relay andone-to-one communication (between UEs directly and between UEs overLTE-Uu).

PC6:

This reference point may be used for functions such as ProSe Discoverybetween users which are subscribed to different PLMNs.

SGi:

In addition to the relevant functions defined in TS 29.061 [10] via SGi,it may be used for application data and application level controlinformation exchange.

FIG. 3 is a schematic view showing a secure system of an exemplaryembodiment of the present invention. As shown in FIG. 3, a secure system1 of an exemplary embodiment of the present invention includes one ormore requesting UEs L01, an operator network L02, and one or morereceiving UEs L03. A method of performing a secure communicationincludes steps of a secure group management L1, a secure discovery L2,an initial authorization L3, an authentication L4, an authorization L5,a security association establishment L6, a secure communication L7, anda termination L8, which are performed between UEs (the requesting UEL01, the receiving UE L03) with or without interacting with the operatornetwork L02.

Assuming that the network coverage is available for UEs, broadcasting ispresented as an example in this exemplary embodiment, but this exemplaryembodiment also applies to multiple-casting and one-to-onecommunications as shown in FIGS. 1A, 1B, and 2.

From setting up of a group till communication termination, security isneeded in each step as described below. Note that steps L1-L4 can be ina different order depending on the service or application.

L1: Secure Group Management

Members can join securely, members can leave securely, and anauthorization level of service and each of the members, and any otherrequired information can be modified securely.

L2: Secure Discovery Should Happen

If discovery is not secured, a device may start communication with awrong party or a rogue device, with the result that masquerading attackscan happen that in turn could lead to fraudulent charging. For thispurpose, the discovery related communication must be secured, i.e., a UEauthenticates identity of other UEs in proximity; integrity protectionfor discovery and a device should be able to authenticate the message.

L3: Initial Authorization

The initial authorization based on secure discovery will lead to thedecision that the discovered device belongs to the group, and thus thenext step can start.

L4: Authentication

Once the device is discovered and authorized as a part of the group,there should be a mutual authentication; otherwise there is still ascope of attacks.

L5: Authorization

The next level of authorization will find out what services can be usedbetween the devices which belong to the same group. For example, a UE isallowed to send and receive different types of messages or is onlyallowed to receive broadcasting messages.

L6: Security Association Establishment (Key Derivation and Management)

The UEs which belong to the same group should have keys to protect theircommunication such that other UEs which do not belong to the group or anattacker cannot eavesdrop or alter the messages.

L7: Secure Communication

The communication between UEs in the same group can be protected by thesecurity association, with integrity and/or confidentiality protectionaccording to the subscription service type.

L8: Termination

The secure termination can provide security when UE(s) suspend orterminate the communication, or when the entire group communication isterminated.

The detailed method of performing a secure communication of an exemplaryembodiment of the invention that fulfills the security requirements willbe explained in the following sections. FIG. 4 is a sequence diagramexplaining a method of making a secure communication between UE 100 andnetwork 200 of an exemplary embodiment of the invention.

[1] Group Setting and Management (L1)

A group can be

-   (1) two devices communicating with each other (one-to-one), or-   (2) more than two devices (one-to-many) where one UE can communicate    with the other devices.-   (3) more than two devices (many-to-many) that can communicate with    each other.

A group can be set up for different communication purposes, and groupmembers can be changed. To form a group, the operator network L02 cancheck the requesting UE L01 which requests the UE L03 which it wants tocommunicate with, verify devices if they can communicate with eachother, and inform the verified devices at both sides (the requesting UEL01 and the receiving UE L03) of the request and formation.

Hereinafter one example of creating a group will be explained. As shownin FIG. 4, a UE 100 requests ProSe subscription to a network 200 andcreates a group (Step 1). In step 1, the UE 100 needs to meetconditions, that is policy, e.g. interest, specific location etc. Alsothe network 200 needs to verify whether UE meets conditions, that ispolicy, e.g. proximity range, subscription, home network in case ofroaming UE, WiFi or not, ProSe enabled, etc. The group is strictlyformed, for example, the members of the group should be registered in awhitelist, or the group is dynamically formed on a request from the UE100, or by the network 200 if the network 200 knows all UE conditions.

For creating a secure group, UEs 100 must agree to be a part of thegroup, and only “agreed” UEs 100 become group members. A groupmanagement includes adding group members, removing group members, endingthe group, and adding temporary group members. Each UE 100 can see whois in proximity from e.g. a social network application, and requests forProSe service, and the ProSe server needs to perform the authorization,but does not have to perform discovery.

[2] Discovery—Secure Detection of UEs in Proximity (L2)

Discovery and group creation in [1] can happen at the same time or beindependent procedure.

There can be following three means that a UE (the requesting UE L01) candiscover other UEs (the receiving UEs L03) in proximity: (1) Broadcastbased, (2) Network based, and (3) Device service level informationbased. How secure discovery can be done will be described as follows.

[2-1] Broadcast Based Solution

There are six ways (s1-s6) in Broadcast based solution:

(s1) Token

The broadcast message can contain a token that only the given UEs canhave. The token should be used only once to prevent the receiving sidefrom reusing it. In order to reach that, the UEs can calculate a tokeneach time on receiving the broadcast message, or the network can informall the UEs of the token to be used next. This can be used for such ause case as an information notification kind of service, since the tokencan be reused by the receiving side.

(s2) Signing Message

The broadcast message can be signed by a key that can be verified eitherby the receiving UEs or by the network for the receiving UEs. Signingcan happen by different key management solutions or it can happen usingthe current keys for communicating with the infrastructure network (orderivation from current keys)—a new key hierarchy might be needed here.

(s3) Message ID

The broadcast message can have an ID that can be verified during theauthentication and is used initially only for authorization.

(s4) Random Value

The broadcast message can contain a random value that can only begenerated by the network and UE. Verification of the random value isdone by the network on behalf of communicating UEs.

(s5) Key

Each UE has a specific key belonging to other devices, and thus it sendsa potentially long broadcast or a new type of broadcast that is sent inpieces with encrypted/integrity protected parts for each UE in thegroup.

(s6) Stamp

The broadcast message can be signed with time-stamp and life-time. Notethat this life-time can be a very short period or can last until thenext broadcast.

[2-2] Network Based Solution

A network can provide information. For this purpose, the network can usethe location information received from the UE (the requesting UE L01),and the location information can be protected by the existing networksecurity mechanism.

[2-3] Device Service Level Information Based Solution

The requesting UE L01 can use location information provided by a socialnetwork or other services. Security can be ensured in an applicationlayer.

Detailed examples of the discovery will be explained. The UE 100 can setfeatures and/or capabilities of Discovery/Discoverable in D2D(device-to-device communication) server.

Case 1A:

If the UE 100 does not know whether the other UEs are in proximity, theUE 100 can request the ProSe server for the ProSe service, and the ProSeserver can send out the request for the ProSe service and meanwhile getthe other UEs location information.

Case 2A:

If the UE 100 can see who is in proximity from e.g. a social networkapplication, and asks for service, the ProSe server needs to perform theauthorization but does not have to perform Discovery.

If the ProSe server performs the authorization, the UEs 100 enable theProSe and/or UEs 100 to be allowed to get given service/communicationmeans.

If the discovery is done based on the proximity of UEs 100, the UE 100sends location information periodically protected by a unicast securitycontext. The network 200 requests location information when needed orperiodically. The request (step 3) can be broadcasted, and thebroadcasted message requires security. The response (step 4) can beprotected by the unicast security context.

The Network stores the conditions for proximity, which can also be givenby the requesting and receiving UE. The network 200 can broadcast to thereceiving UEs in a neighborhood which are allowed to be discovered, andthe UEs respond with protected messages. The UE 100 informs the network200 of its conditions and capabilities at a first communication and/orregistration or when any change happens.

The broadcast based solutions by the network 200 or the UE 100 requireone or more of the following requirements. That is, the receiving sideshould be able to verify the source, the broadcast message should not bere-used, the network 200 which receives the response should be able toverify it, or the response should be discarded if it is too long. The UE100 can use one or more of solutions for performing secure discovery.The solutions include a token, a sign, a message, a message ID, a randomvalue, keys, and stamps. Note that those solutions can be used in thestep 5 (mutually authenticate, the authentication L4), in the step 6(authorize, the authorization L5), and in the step 7 (generate keys andnegotiate algorithm, the secure communication L7), as shown in FIG. 4.The steps 5 to 7 can happen together, and might be related to broadcastsecurity.

[3] Initial Authorization (L3)

The initial authorization varies according to the above discoverysolution.

[3-1] Broadcast Based:

Whether the requesting UE L01 is allowed to communicate with thereceiving UE L03 can be checked by a network or by the receiving UE L03having a proof provided by the network.

[3-2] Network Based:

The requesting UE L01 and the receiving UE L03 can perform a mutualauthentication over the direct wireless interface.

[3-3] Device Service Level Information Based:

The receiving UE L03 checks a list maintained by the user or in a UEamong the members of the group of devices for ProSe service purpose.

[4] Authentication (L4)

Once the requesting UE L01 is identified as belonging to the same group,then authentication takes place. Authentication can be carried outlocally or by interacting with the network.

[4-1] Authentication of the Requesting UE L01:

This can be performed by successful identification of the requesting UEL01 by a network or a UE with a proof from a network.

[4-2] Authentication of the Receiving UE L03:

This can be performed by

-   [4-2-i] using a key shared between the requesting UE L01 and the    receiving UE L03-   [4-2-ii] using current network security keys or new keys-   [4-2-iii] a network which informs the requesting UE L01 of the    incoming authentication request from the receiving UE L03.

[5]Authorization—Service Access Control (L5)

There should be different levels for access control to services that therequesting UE L01 and the receiving UE L03 (hereinafter also referred toas “UE”) can use within the group.

-   [5-1]UE is allowed to receive and/or send a broadcasting message.-   [5-2]UE is allowed to receive and/or send multiple messages.-   [5-3]UE is allowed to receive and/or send a message for one-to-one    communications.-   [5-4] UE authorization according to subscription information and the    policy UE set for ProSe service.

A network can set up and provide the policy to the group membersincluding the requesting UE L01 and the receiving UE L03 according to UEcapabilities and user subscriptions.

The network 200 performs authorization for the UEs 100 want to join thegroup. The group member of UEs 100 verify whether other UEs areauthorized by the network by using the session keys. Another method forperforming validated authorization is done by (1) a network sending anauthorization value to each UE 100, and each UE 100 uses this value toperform authorization on each other, or (2) Yet another method forperforming a validated authorization is done by sending an authorizationvalue from a requesting UE to a receiving UE, and then the receiving UErequests the Network to validate this authorization value and receivingresult.

[6] New Key Hierarchy and Key Management (L6)

A new key hierarchy is presented in this exemplary embodiment of theinvention. Key Kp is a key related to the group and also may related toa ProSe service. It has an indicator KSI_p related to it. Kp can be sentfrom ProSe Server to use.

Keys, Kpc and Kpi are session keys that are derived from Kp at UEs. Kpcis a confidentiality key and Kpi is an integrity protection key. Thesession keys are used for UE to perform authorization for each other,and ProSe communication setup, and have the direct communication betweenthem.

After authorization and authentication, the communicating devicesincluding the requesting UE L01 and the receiving UE L03 can startsessions to communicate with each other. When the requesting UE L01 andthe receiving UE L03 communicate with each other, they should sharecommunication keys. The keys can be a group key, and/or a unique key percommunicating device as well as a session key per each session.

The key can be managed by the network and sent over the securecommunication channel with the network. Alternatively, the key can bemanaged by the requesting UE L01 and sent to other devices including thereceiving UE L03 in the communication, over a secure unicastcommunication channel that can be secured by the network duringauthentication or verification. The key can also be issued by a thirdtrusted party.

The UEs 100 authenticate each other at the beginning of a session (S5).The authentication is linked to authorization (S6). FIGS. 5A to 5C areschematic views showing One-to-one, One-to-many, and Many-to-manysessions, respectively. As shown in FIGS. 5A to 5C, a UEa 21 and a UEa31 indicate the requesting UE L01, and a UEb 22, a UEb 32, a UEc 33 anda UEn_33 n indicate the receiving UE L03.

When the session is started, firstly session keys are generated. In thisexemplary embodiment, the requesting UE L01 (UEa 21, the UEa 31) and thereceiving UE L03 (UEb 22, the UEb 32, the UEc 33, the UEn_33 n) use twokinds of keys including session keys.

Case 1B:

Each group has a key Kp for each service (Kp is served as a service key)and a new session key is created for each session.

Case 2B:

Each group has the key Kp (Kp is served as a group key), and a newsession key is created for each session.

In each case, either the ProSe server or the requesting UE L01 sendskeys. For example, the ProSe server sends the key Kp to the requestingUE L01 and the receiving UE(s) L03, and the requesting UE L01 sends asession key to the receiving UE(s) L03 every session. Alternatively, theProSe server sends both of the key Kp and the session key to therequesting UE L0 and the receiving UE(s) L03, or the requesting UE L01sends both of the key Kp and the session key to the receiving UE(s) L03.

Further, when the group changes if someone leaves or is added, when asession ends or a key times out, or when the ProSe server has made adecision, for example, the key Kp and/or the session key should bechanged.

If the ProSe Server allocates the key Kp to UEs, UEs derive session keysfrom that for authorization and communication. UEs can be pre-configuredwith algorithms for key derivation, or the key Kp is related to a KSI(key set identifier) and a service. Because of them, the securityproblems during UEs' authentication and authorization or the securityproblems of a key for direct communication may be solved.

Note that the key set identifier (KSI) is a number which is associatedwith the cipher and integrity keys derived during the authentication.The key set identifier can be allocated by the network and sent with theauthentication request message to the mobile station where it is storedtogether with a calculated cipher key CK and an integrity key IK. Thepurpose of the key set identifier is to make it possible for the networkto identify the cipher key CK and integrity key IK which are stored inthe mobile station without invoking the authentication procedure. Thisis used to allow re-use of the cipher key CK and integrity key IK duringsubsequent connections (session).

[7] Secure Communication (L7)

Secure communication can provide message transmission availabilitybetween group member UEs, as well as preventing a message from beingeavesdropped on or altered by UEs that do not belong to the group. Alsothe secure communication can prevent UE from using an unauthorizedservice.

The communication within the group should have integrity and/orconfidentiality protection. All the communications can be protected bythe session keys described above, after the security association isestablished.

The security policy can be a negotiation and an agreement within thegroup with or without the support of the operator network L02. All thegroup members should follow the security policy.

Next, the security in the case where UEs' location change happens willbe explained. If none of UEs has a location change, there is no securityissue. Further, if all of the UEs have a changed location, but stayed inproximity to each other, then there is still no security issue.

If a part of UEs (one or more UEs) have moved out of proximity fromother UEs and they do not use the ProSe service, group and securitymanagement need to be updated for the remaining UEs in the group.Alternatively, if one or more UEs have moved out of proximity from theUEs and they want to keep the ProSe service with each other, group andsecurity management need to be updated for the remaining UEs in thegroup, and a new group and security are needed for the traveler.

Note that the ProSe Server should get UE location information from GMLC(Gateway Mobile Location Center) periodically, to compare and computethe location differences of all UEs.

[8] Termination (L8)

When the communication is to be suspended, devices should remove thesession key while keeping information of the authentication andauthorization.

When the communication is to be terminated, the devices can keep historyinformation, or the allocated token with a lifetime for the next usetime to prevent signaling for authentication and authorization again.

Smooth handover from an infrastructure to a direct mode will requirecreation of a key between communicating parties (the requesting UE L01and the receiving UE L03) before a handover happens. For example, ifcommunicating parties are using WiFi, a key should be allocated to WiFiAP and UEs. The WiFi AP and UEs should authorize and authenticate eachother. The key should have a limited life-time. A network can recognizewhich WiFi AP the UE can communicate with. UEs can find that there is aWiFi AP nearby and the network verifies the WiFi AP. UEs authenticatewith the ProSe Server when UEs connect to a WiFi AP. One option is thatthe ProSe Function can allocate keys for the UEs to communicate with aProSe APP Server.

To summarize the above description, the method of making a securecommunication of an exemplary embodiment includes the followingfeatures:

-   (1) The operator network L02 determines whether the requesting UE    L01 can communicate with the receiving UE L03 requested by the    requesting UE L01.-   (2) Security in discovery of UEs in proximity can be provided by    using a token, a key, and signing provided by the network.-   (3) Security in discovery of UEs in proximity can be provided by    using a location provided by the operator network L02.-   (4) Security in discovery of UEs in proximity can be provided by    using location information provided by social network services, with    security provided in an application layer.-   (5) Authorization of the devices can be performed by the network or    by devices direct verification.-   (6) Mutual authentication between the requesting UE L01 and the    receiving UEs that agreed to be in the group L03 can be carried out    by the network and also both UEs can be informed with the result.-   (7) Mutual authentication between the requesting UE L01 and the    receiving UEs L03 can be carried out by both ends with a key shared    there between.-   (8) New keys for securing the ProSe communication which are a group    key and a unique session key can be used.-   (9) Security policy in a group for secure communication is    negotiated and set.-   (10) Termination management can be performed to prevent the same    keys from being used and set up a security context for other    communication.

According to the secure system of an exemplary embodiment, the operatornetwork L02 can determine the receiving UE(s) L03 with which therequesting UE L01 can communicate, and can ensure secure discovery byeither providing security parameters to the requesting UE L01 orreceiving UE L03, and providing location information of the receiving UEL03 to the requesting UE L01. Furthermore, the operator network L02 canperform authentication and authorization for the requesting UE L01 andreceiving UE L03, and can support security association between UEs tosecure ProSe communication.

[9] A Detailed Method of Performing the Authentication and Authorization

Next, a more detailed method of performing the authentication andauthorization, and establishing the security association with each otherfor the direct communication will be explained.

As described above, there are three types of direct communicationbetween UEs, i.e. 1) One-to-one, 2) One-to-many, and 3) Many-to-many asshown in FIGS. 5A, 5B, and 5C, respectively.

A UEa is a Requesting UE. A UEb, a UEc, and other UEs are Receiving UEs.The UEs set up direct communication with each other and protect thecommunication with keys they share.

A new key hierarchy is presented in this invention. Key Kp is a keyrelated to the ProSe service ID, and has an indicator KSI_p related toit. Kp can be sent from the ProSe Server to UEs in a ProSe ServiceResult message, or can be sent from the ProSe Server when UEs areregistered to the ProSe Server. Kpc and Kpi are session keys derivedfrom Kp at UEs. Kpc is a confidentiality key and Kpi is an integrityprotection key. The session keys are used for ProSe communication setupand the direct communication between them.

Assuming that UEs are authenticated to the network and registered to theProSe Server. The Discovery procedure is completed as described above.The detail message sequence and description of the three cases are givenbelow.

[[Case 1C]] One-to-One Direct Communication

There are only two UEs in proximity having direct communication witheach other. In one-to-one communication, Kp can also be allocated to UEsat UE registration to the ProSe server. Considering the one-to-one typeof communication is rather for a dynamic demand, not dedicated to acertain type of service, it is more efficient that the ProSe serverdistributes the keys when the communication is required.

FIG. 6 is a sequence diagram showing One-to-one communication of anexemplary embodiment of the present invention. As shown in FIG. 6, thesystem includes a UEa 31, a UEb 32, a ProSe server 34, and an operatornetwork 36. The method includes the following 12 steps.

-   SP20: The UEa 31 and the UEb 32 are pre-configured with key    derivation algorithms, respectively.-   SP21: When the Verification in [4] step 8 is successfully completed,    the ProSe server 34 can allocate (an existing) or derive (a new) key    Kp.-   SP22: The ProSe server 34 sends Kp, KSI_p, UEb ID, and a service ID    in the ProSe Service Result to the UEa 31.-   SP23: The ProSe server 34 sends Kp, KSI_p, UEa ID, and a service ID    in the ProSe Service Result to the UEb 32.-   SP24: The UEa 31 derives the session keys Kpc and Kpi from the Kp    which is received from the ProSe server 34.-   SP25: The UEa 31 sends ProSe Communication Setup to UEb 32 with a    service ID, KSI_p, UEa ID, and an algorithm for session key    derivation. This message is integrity protected with Kpi.-   SP26: The UEb 32 derives the same session keys Kpc and Kpi from the    Kp which is received from the ProSe server 34. The UEb 32 can    determine which Kp is to be used according to the KSI_p and the    service ID received in SP25.-   SP27: The UEb 32 performs integrity check on the message received in    SP25 with the derived Kpi. The UEb 32 can also further check if the    UEa ID and service ID are the same as those received in SP23.-   SP28: If the Verification at SP27 is successful, the UEb 32 sends a    ProSe Communication Accept with the service ID and UEb ID to the UEa    31. The message is integrity protected with Kpi. It goes to SP30.-   SP29: If the Verification at SP27 fails, the UEb 32 sends a ProSe    Communication Reject with the service ID, UEb ID, and a proper cause    to the UEa 31.-   SP30: The UEa 31 performs integrity check on the ProSe Communication    Accept with the Kpi. The UEa 31 can also further check UEb ID and    service ID. Direct Communication can start thereafter if the    verification is successfully completed.-   SP31: Direct communication starts between the UEa 31 and the UEb 32.    The messages can be confidentiality and/or integrity protected by    the session keys Kpc and Kpi.

[[Case 2C]] One-to-Many Communication

There is a group of UEs having direct communication in which therequesting UE can send broadcasting messages to other member UEs in thegroup, and other member UEs can communicate with the requesting UE butdo not communicate with other UEs in the same group.

In this exemplary embodiment, two options for how Kp can be allocated toUEs will be explained. The following is option 1 that Kp is sent fromthe ProSe server 34 in ProSe Service Result, which is the same as inOne-to-one communication shown in FIG. 6.

FIG. 7 is a sequence diagram showing the option 1 of One-to-Manycommunication of an exemplary embodiment of the present invention. Asshown in FIG. 7, the method includes the following steps.

-   SP40: The UEa 31, the UEb 32, and the UEc 33 are pre-configured with    key derivation algorithms, respectively.-   SP41: When the Verification in [4] step 8 is successfully completed,    the ProSe server 34 can allocate (an existing) or derive (a new) key    Kp.-   SP42: The ProSe server 34 sends Kp, KSI_p, a UE ID list of the    allowed UEs, and a service ID in the ProSe Service Result to the UEa    31.-   SP43 a and SP43 b: The ProSe server 34 sends Kp, KSI_p, UEa ID, UE    ID list of the allowed UEs, service ID in the ProSe Service Result    to the UEb 32 and the UEc 33, respectively.-   SP44: The UEa 31 derives the session keys Kpc and Kpi from the Kp    which is received from the ProSe server 34.-   SP45 a and SP45 b: The UEa 31 sends ProSe Communication Setup to the    UEb 32 and UEc 33 with a service ID, KSI_p, UEa ID, and an algorithm    for session key derivation, respectively. This message is integrity    protected with Kpi.-   SP46: The UEb 32 and UEc 33 derive the same session keys Kpc and Kpi    from the Kp which is received from the ProSe server 34,    respectively. The UEb 32 and UEc 33 can determine which Kp is to be    used according to the KSI_p and service ID received in SP45 a and    SP45 b, respectively.-   SP47: The UEb 32 and UEc 33 perform integrity check on the message    received in SP45 a and SP45 b, respectively, with the derived Kpi.    The UEb 32 and UEc 33 can also further check if the UEa ID and    service ID are the same as those received in SP43 a and SP43 b,    respectively.-   SP48 a and SP48 b: If the Verification at SP47 is successful, the    UEb 32 and UEc 33 send ProSe Communication Accept with a service ID    and a UEb/UEc ID to the UEa 31, respectively. The message is    integrity protected with Kpi. It goes to SP50.-   SP49 a and SP49 b: If the Verification at SP47 fails, the UEb 32 and    UEc 33 send ProSe Communication Reject with the service ID, UEb/UEc    ID, and a proper cause to the UEa 31, respectively.-   SP50: The UEa 31 performs integrity check on the ProSe Communication    Accept with the Kpi. The UEa 31 can also further check UEb/UEc ID    and service ID. Direct Communication can start thereafter if the    verification is successfully completed.-   SP51: Direct communication starts between the UEa 31 and the UEb 32,    or the UEa 31 and the UEc 33. The messages can be confidentiality    and/or integrity protected by the session keys Kpc and Kpi.

The following is the option 2 that receiving UEs (UEb 32, UEc 33)receive Kp at registration to the ProSe server 34. In this option, theProSe server 34 does not need to send the ProSe Service Result to eachof the receiving UEs (UEb 32, UEc 33). This will save network resourcewhen there are many UEs in the group for direct communication.

FIG. 8 is a sequence diagram showing the option 2 of One-to-Manycommunication of an exemplary embodiment of the present invention. Asshown in FIG. 8, the method includes the following 10 steps.

-   SP60: Kp is allocated to UEs when they are registered to ProSe    server 34. The UEa 31, UEb 32, and UEc 33 are pre-configured with    key derivation algorithms, respectively.-   SP61: The ProSe server 34 sends KSI_p, a UE ID list of the allowed    UEs, and a service ID in the ProSe Service Result to the UEa 31.-   SP62: The UEa 31 derives the session keys Kpc and Kpi from the Kp.-   SP63: The UEa 31 broadcasts ProSe Communication Setup to the UEs in    the UE ID list, with the service ID, UEa ID, UE ID list, and KSI_p.    This message is integrity protected with Kpi.-   SP64: UEs having received the broadcast message sees if it is on the    list, and derives the same session keys Kpc and Kpi from the Kp. UEs    can determine which Kp is to be used according to the KSI_p and    service ID received in SP63.-   SP65: The UEb 32 and UEc 33 perform integrity check on the broadcast    message with the derived Kpi. The UEb 32 and UEc 33 can also further    check the UEa ID and service ID, if there are pre-configured    criteria, respectively.-   SP66 a and SP66 b: If the Verification is successful, the UEb 32 and    UEc 33 send ProSe Communication Accept with a service ID and UEb/UEc    ID to the UEa 31, respectively. The message is integrity protected    with Kpi. It goes to SP68.-   SP67 a and SP67 b: If the Verification fails, the UEb 32 and UEc 33    send ProSe Communication Reject with the service ID, UEb/UEc ID, and    a proper cause to the UEa 31, respectively.-   SP68: The UEa 31 performs integrity check on the ProSe Communication    Accept with the Kpi. The UEa 31 can also further check the UEb/UEc    ID and service ID. Direct Communication can start thereafter if the    verification is successfully completed.-   SP69: Direct communication starts between the UEa 31 and the UEb 32,    or the UEa 31 and the UEc 33. The messages can be confidentiality    and/or integrity protected by the session keys Kpc and Kpi.

[[Case 3C]] Many-to-Many Communication

In Many-to-many communication, each UE can communicate with any otherUEs in the group. FIG. 9 is a sequence diagram showing Many-to-manycommunication of an exemplary embodiment of the present invention. Asshown in FIG. 9, the method includes the following 10 steps.

-   SP70: Kp is allocated to UEs when they are registered to the ProSe    server 34. The UEa 31, UEb 32, and UEn 33 n are pre-configured with    key derivation algorithms, respectively.-   SP71: The ProSe server 34 sends KSI_p, a UE ID list of the allowed    UEs, and a service ID in the ProSe Service Result to the UEa 31.-   SP72: The UEa 31 derives the session keys Kpc and Kpi from the Kp.-   SP73: The UEa 31 broadcasts ProSe Communication Setup to the UEs in    the UE ID list, with the service ID, UEa ID, UE ID list, and KSI_p.    This message is integrity protected with Kpi.-   SP74: UEs having received the broadcast message sees if it is on the    list, and derives the same session keys Kpc and Kpi from the Kp,    respectively. UEs can determine which Kp is to be used according to    the KSI_p and service ID received in SP73, respectively.-   SP75: The UEb 32 and UEn 33 n perform integrity check on the    broadcast message with the derived Kpi, respectively. The UEb 32 and    UEn 33 n can also further check UEa ID and service ID, if there are    pre-configured criteria, respectively.-   SP76 a and SP76 b: If the Verification is successful, the UEb 32 and    UEn 33 n send ProSe Communication Accept with the service ID and    UEb/UEn ID to the UEa 31, respectively. The message is integrity    protected with Kpi. It goes to SP78.-   SP77 a and SP77 b: If the Verification fails, the UEb 32 and UEn 33    n send ProSe Communication Reject with the service ID, UEb/UEn ID,    and a proper cause to the UEa 31, respectively.-   SP78: The UEa 31 performs integrity check on the ProSe Communication    Accept with the Kpi. The UEa 31 can also further check the UEb/UEn    ID and service ID. Direct Communication can start thereafter if the    verification is successfully completed.-   SP79: Direct communication starts between UEs. The messages can be    confidentiality and/or integrity protected by the session keys Kpc    and Kpi.

To summarize the above description, a method of performingauthentication and authorization of an exemplary embodiment includes thefollowing features:

-   (1) New key hierarchy for UEs direction communication: Kp and    session keys Kpc and Kpi. Kpc is for encryption and Kpi is for    integrity protection. Both Kpc and Kpi are derived from Kp.-   (2) Kp is related to a key identifier KSI_p and also a service ID,    such that UEs can keep the synchronization and verify whether the    key is proper for the requested service.-   (3) The ProSe server distributes Kp to UEs when UEs are registered    to the ProSe server, or in the ProSe Service Result message.-   (4) UEs are pre-configured with algorithms for session key    derivation. By the KSI_p, service ID and indicated algorithm, the    receiving UEs can derive the same session keys.-   (5) Integrity key Kpi is used to protect the communication request    from the requesting UE, such that the receiving UE can perform    integrity check and verify whether the message is from an authorized    source.-   (6) Receiving UE can also verify whether all the service ID, the    requesting ID, and the key match.-   (7) ProSe Communication Accept is integrity protected by the    receiving UE such that the requesting UE can verify its integrity.-   (8) Direct communication between UEs can be confidentiality and/or    integrity protected with the session keys Kpc and Kpi.

According to the secure system of an exemplary embodiment the invention,the key distributed from a network element ProSe server enables the UEswhich want to establish direct communication to verify whether the otherUEs are authorized to have the service. The UEs derive session keys attheir ends can prevent keys from being stolen or altered if they aresent from one UE to another. The Kp is related to a certain service,which prevents the UEs from using the key for other services which theymay not be authorized to have. The direct communication between UEs canbe secured with the session keys that are shared only between the UEs.

This software can be stored in various types of non-transitory computerreadable media and thereby supplied to computers. The non-transitorycomputer readable media includes various types of tangible storagemedia. Examples of the non-transitory computer readable media include amagnetic recording medium (such as a flexible disk, a magnetic tape, anda hard disk drive), a magneto-optic recording medium (such as amagneto-optic disk), a CD-ROM (Read Only Memory), a CD-R, and a CD-R/W,and a semiconductor memory (such as a mask ROM, a PROM (ProgrammableROM), an EPROM (Erasable PROM), a flash ROM, and a RAM (Random AccessMemory)). Further, the program can be supplied to computers by usingvarious types of transitory computer readable media. Examples of thetransitory computer readable media include an electrical signal, anoptical signal, and an electromagnetic wave. The transitory computerreadable media can be used to supply programs to computer through a wirecommunication path such as an electrical wire and an optical fiber, orwireless communication path.

This application is based upon and claims the benefit of priority fromJapanese Patent Application No. 2013137293, filed on Jun. 28, 2013, thedisclosure of which is incorporated herein in its entirety by reference.

REFERENCE SIGNS LIST

1 secure system

10 system

11 UE

12 UE

13 E-UTERN

14 EPC

15 ProSe Function

16 ProSe APP Server

17 ProSe APP

18 ProSe APP

19 eNB

20 eNB

21 UEa

22 UEb

31 UEa

32 UEb

33 UEc

33 n UEn

34 ProSe server

36 operator network

100 UE

100 a system

100 b system

200 network

L01 requesting UE

L02 operator network

L03 receiving UE

L1 secure group management

L2 secure discovery

L3 initial authorization

L4 authentication

L5 authorization

L6 security association establishment

L7 secure communication

L8 termination

1. A method of performing authentication and authorization in Proximitybased Service (ProSe) communication by a requesting device which sends arequest of a communication and a receiving device which receives therequest from the requesting device, the method comprising: derivingsession keys Kpc and Kpi from an unique key Kp at the requesting andreceiving devices; using the session keys Kpc and Kpi for ProSecommunication setup and direct communication between the requesting andreceiving devices; and starting the direct communication with therequesting and receiving devices, wherein the key Kpc is confidentialitykey and the key Kpi is integrity protection key.
 2. The method ofperforming authentication and authorization in ProSe communicationaccording to claim 1 further comprising: requesting a ProSe servicerequest to the ProSe server from the requesting device; performing adiscovery procedure by the ProSe server to obtain location informationof the receiving device; and sending a ProSe service result to therequesting and receiving devices, wherein the key Kp is sent from theProSe Server to the requesting and receiving devices in the ProSeservice result.
 3. The method of performing authentication andauthorization in ProSe communication according to claim 2, wherein thedirect communication is one-to-one communication between the requestingand receiving devices.
 4. The method of performing authentication andauthorization in ProSe communication according to claim 2, wherein thedirect communication is one-to-many communication between the requestingdevice and a plurality of the receiving devices in a same group, andwherein the requesting device can send broadcasting messages to otherreceiving devices in the same group, and other devices can sendbroadcasting messages to the requesting device but cannot sendbroadcasting messages each other.
 5. The method of performingauthentication and authorization in ProSe communication according toclaim 1 further comprising: sending the key Kp from the ProSe Serverwhen the requesting and receiving devices are registered to the ProSeServer; requesting a ProSe service request to the ProSe server from therequesting device; performing a discovery procedure by the ProSe serverto obtain location information of the receiving device; and sendingdevice ID list of allowed receiving devices, service ID in a ProSeservice result to the requesting device.
 6. The method of performingauthentication and authorization in ProSe communication according toclaim 2, wherein the direct communication is one-to-many communicationbetween the requesting device and a plurality of the receiving devicesin a same group, and wherein the requesting device can send broadcastingmessages to other receiving devices in the same group, and other devicescan send broadcasting messages to the requesting device as well as eachother.
 7. A secure system including a plurality of User Equipments(UEs), and a Proximity based Service (ProSe) server comprising: arequesting device which sends a request of a communication; and areceiving device which receives the request from the requesting device,wherein the requesting and receiving devices derive session keys Kpc andKpi from an unique key Kp; the requesting and receiving devices use thesession keys Kpc and Kpi for ProSe communication setup and directcommunication between the requesting and receiving devices; and therequesting and receiving devices start the direct communication with therequesting and receiving devices, wherein the key Kpc is confidentialitykey and the key Kpi is integrity protection key.